home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 16833 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  2.7 KB
  1. Path: solon.com!not-for-mail
  2. From: seebs@solutions.solon.com (Peter Seebach)
  3. Newsgroups: comp.lang.c++,comp.lang.c,comp.os.ms-windows.programmer.misc
  4. Subject: Re: fastest code
  5. Date: 12 Apr 1996 07:44:02 -0500
  6. Organization: Usenet Fact Police (Undercover)
  7. Message-ID: <4klj6i$nka@solutions.solon.com>
  8. References: <316112A2.7D37@public.sta.net.cn> <4kgu7g$n9a@solutions.solon.com> <4kjc9n$f7j@samba.rahul.net> <316E1037.41C67EA6@scn.de>
  9. Reply-To: seebs@solon.com
  10. NNTP-Posting-Host: solutions.solon.com
  11.  
  12. In article <316E1037.41C67EA6@scn.de>,
  13. Gerolf Wendland  <wendland%hpp015%hpp001.mch2.scn.de@scn.de> wrote:
  14. >Whoever started this, he wrote:
  15.  
  16. >> >>: >>           for (i=0; i<16; i++)
  17. >> >>: >>                   prom[i] = prom[i+i];
  18.  
  19. >> >>: HUH?  the code as written has a clear effect, which is to shove all of
  20. >> >>: the elements of an array over one.  It certainly is an optimizer bug.
  21.                                                              ^^^^^^^^^^^^^^
  22. >Really?
  23.  
  24. Well, it doesn't shove them over one.  But, if you notice, the 2nd subscript
  25. is *different* from the first.  The effect of this would presumably be to
  26. put every other value in the first half of the locations.
  27.  
  28. >Richard Krehbiel:
  29. >>In fact, I wrote exactly this loop once whose purpose was to initialize the
  30. >>parity bits in memory, but be non-destructive in case it was just a
  31. >>restart and not a power-on.
  32.  
  33. [By which, as I recall, he was talking about a loop with foo[i] = foo[i];]
  34.  
  35. >This seems to indicate that prom[i] are assigned a values that are never used.
  36. >Maybe the optimizer has seen this. It should have issued a warning, which (the
  37. >issueing) may have been prevented by not prom being the variable but by the 
  38. >somewhat anonymous locations prom[i] being the variables in question. The
  39. >optimizer would have been even better if it had seen the fact that the loop
  40. >is superflouos and had removed it as well.
  41.  
  42. >The volatile keyword is surely a good way to circumvent this problem.
  43.  
  44. It may work in this case, but it certainly shouldn't, if the values are ever
  45. used.  If they aren't ever used, there's no way to tell that the code isn't
  46. running "correctly", so we assume they're used.
  47.  
  48. It is almost never correct for a compiler to optimize out an assignment
  49. within a loop.  Assuming that the program can tell in some way whether or
  50. not the assignments happened, it's an optimizer bug.
  51.  
  52. (If the program can't tell, of course, then by the as-if rule, it's not
  53. a bug.)
  54.  
  55. -s
  56. -- 
  57. Peter Seebach - seebs@solon.com - Copyright 1996 Peter Seebach.
  58. C/Unix wizard -- C/Unix questions? Send mail for help.  No, really!
  59. FUCK the communications decency act.  Goddamned government.  [literally.]
  60. The *other* C FAQ - http://www.solon.com/~seebs/c/c-iaq.html
  61.